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i.O INTRODUCTION 


This report offers alternative concepts for a common dertign for the 
UARS and OPEN Central Data Handling Facility (CDHF) (see Section 4). The 
designs are consistent with requirements shared by UARS and OPEN (Section 
2) and the data storage and data processing demands of these missions 
(Section 3). Because more detailed information is available for UARS, the 
design approach has been to size the system and to select components for a 
UARS COHF, but in a manner that does not optimize the CDHF at the expense 
of OPEN. Costs for alternative implementations of the UARS designs are 
presented in Sections 4.1 and 4.2, showing that the system design does not 
restrict the implementation to a single manufacturer. Processing demands 
on the alternative UARS CDHF implementations are then discussed in Section 
4.3. With this information at hand together with estimates for OPEN 
processing demands (Section 3.2), it is shown that any shortfall in system 
capability for OPEN support can be remedied by either component upgrades or 
array processing attachments rather than a system redesign. 

In addition to a common system design, it is shown in Section 5 Chat 
there is significant potential for common software design, especially in 
the areas of data management software and non-user-unique production 
software. 

The report then gives cost examples for several modes of communica- 
tions between the CDHF and Remote User Facilities (Section 6). The report 
concludes with a discussion of the potential application of technologies 
expected to reach fruition before the mission timeframe (Section 7). 
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2.0 UARS AND OPEN SYSTEM LEVEL REQUIREMENTS 

Based \Apcn available documentation and input Trom GSFC technical 
personnel, a list of OPEN and UARS missions system level requirements, 
assumptions and intercomparisons was generated for the report, in which 
particular emphasis was placed upon the Central Data Handling Facility 
(CDHF). Based upon this Information, it is seen t^at there are a number of 
system level functions common to both a UARS and an OPEN CDHF* The major 
of these common functions are: 

o Data Ingest of playback data 
0 Routine production processing of the data 
o Data management 
o Investigator communications. 

The distribution of these functions within the proposed CDHF concepts 
is defined in Section 4. 

2.1 UARS and OPEN Systems Elements 

Not only do the UARS and OPEN CDflF's share similar system level 
requirements, but their relations to institutional facilities are also 
similar. This is illustrated in Figure 2.1-1. As shown in the figure, in 
addition to the CDHF, both UARS and OPEN ground systems consist of the 
following functional elements; 

• Data capture 

• Orbit determination 

• Attitude determination 

• Command management 

• Payload operations control 
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FIGURE 2.1-1 OPEN-UARS GROUND SYSTEM ELEMENTS 














• Filgtit software 

• Mission planning 

• Conununications 

Additionally, the PX^s will be provided Interactive remote facilities 
suitable for analysis of the processed data. 

The main functions performed by the ground system elements as well as 
the inter-relationships among them are shown in Figure 2.1-1* 
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3.0 DATA STORAGE AMD PROCESSING ANALYSIS 


In order to derive system concepts for processing and managing data 
within the COHF, estimates for their data storage and data processing 
requirements are necessary. These presented In Sections 3.1 and 3.2, 
respectively. 

3.1 PARS and OPEN Storage Analysis 

Available Information allows for an analysis of the requirements for 
data processing and storage. It should be noted, however, that the 
Information available for UARS Is more complete. 

Table 3.1-1 presents PARS data volumes for PARS production processing 
by data category. It Is seen that dally production data volume is about 
740 Mbytes. An on-line storage capacity of about 111 Gbytes of production 
data as well as an additional 9 Gbytes of support data and PI data sub- 
missions from remote sites will be required. 

Table 3.1-2 presents the OPEN storage requirements. These 
requirements have been derived from Information presented In the proposals 
for the OPEN Instruments which have been selected. It Is seen that dally 
production data volume Is about 1.2 Gbytes and that an on-line storage 
capacity of about 418 Gbytes will be required. 

3.2 PARS and OPEN Processing Estimates 

In order to derive system concepts for the CDHF, not only must the 
data requirements be at hand but It Is also necessary to focus upon the 
magnitude of the processing demands upon the CDHF. These are presented for 
PARS and OPEN In the following paragraphs. 
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TABLE 3.1-1 UARS INSTRUMENT DATA STORAGE REQUIREMENTS 





Daily Volume (MB) 



ON-LINE 

INSTRUMENT 



Level 


B 

STORAGE 

m 

(MB) 


0 

1 

2 

3 

Wlnda and T«mp«raturaa 
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1.3 
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14.2 

2.8 

45.5 

9,755 

High Raaolutlon Dopf Ur 
Itnagar (HRDI) 

B 

48.4 

86 

40 

B 

175.0 

24,908 

Cryoganlc Limb Array Etalon 
Spectrometer (CLAES) 

l.l 

12 

32 

10.9 

0.18 

454 O 8 

1 

1,66;\ 

Halogen Occulation 
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l.l 

15.8 

12.5 

B 

0.04 

3 I 4 O 4 I 
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Improved Stratoapherlc and 
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B 

5.4 

2.7 

0.8 

8.3 

17.2 

5,049 
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4.0 

58.8 

90 

61 

31 

240.8 

52,968 

Particle Environment 
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28,5 

109.5 

U f2I 

5 (21 

154.0 

12,321 

Solar Ultraviolet Spectral 
Irradlance Monitor (SUSIM) 

1.0 

10.7 

0.5 

0.23 

0.01 

11.44 

251 

Solar Stellar Irradiance 
Compar. Exper. (SOLSTICE) 

0.1 

iiiiiii^iiiiiiin 

B 

B 

0.02 

1.72 

303 

Solar Backscatter Ultra- 
violet Radiometer (SBUV) [3] 

0.32 

B 

2 

2 

0.4 

6.8 

1,380 

(MAGNETOMETER) [4] 

B 

3.25 

6.5 

- • 

- 

9.75 

116 

TOTAL FROM ALL INSTRUMENTS 

i 

199.95 

356.7 

133.33 

48.35 

738.33 

110,807 


{!] 10 Day LO; 30 Daya LI; 540 Daya L2 and L3 

[2] 10:1 dacrtaaa In data voltima from Ll*^ L2 and 2:1 daeraaaa from L2 L3 (aaclmatad from PI requlramtnc 

for graphlca data) 

[3] Similar to Inatrumant flown on advanead T1R0S*N Sarlaa. 

(41 Supplitd by PEM and uaad by PEM axparimant only. 
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TABLE 3.1-2 OPEN DATA STORAGE REQUIREMENTS 
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Based upon the UARS data processing requirements contained In the 
actual questionnaire responses submitted by the Pis and the CSC study which 
summarizes and synthesizes these responses it is estimated that in order to 
process a day^s production data for the instruments selected a total 
processing load of about 48,000 Million Floating Point Operations (MFLOPS) 
would be required. If these operations could be spread uniformly over an 
8-hour period (one shift) then the effective throughput of the computing 
machinery would be 1.68 MFLOPS/sec. In other words, CPU sizing for 
processing should be in the 2 t4FL0PS/sec (effective throughput) range. 
This estimate does not Include I/O and data management demands. 

Intormation for OPEN data processing which is comparable to the 
results in the CSC study has not yet been developed. However, gross 
estimates can be made for OPEN by extrapolating what is known about UARS 
togeth'U' with analyzing the selected OPEN instrument proposals. When this 
is tU^ne, it is estimated that the ratio of OPEN processing demands to UARS 
processing demands is about 5.2:1. Thus CPU sizing for OPEN data 
processing is about in the 9 MFLOPS/sec range (effective throughput), 
excluding I/O and data management demands. The analysis for deriving this 
estimate is presented in the report. 



4.0 GDUF SYSTEM CONCEPTS 


This section presents two system design approaches for satisfying the 
requirements of either a UARS or an OPEN CDHF. Because the LIARS CDHF is 
assumed to precede the OPEN CDHF, the overall approach has been to size a 
system and select components for a UARS CDHF, but in a manner that does not 
opcimlze the CDHF for UARS at the expense of 0PEN« Indeed, the shortfall 
in system capability for OPEN support could be remedied by component 
upgrades rather than a system redesign. 

In what follows, a detailed analysis Is made for UARS. System 
upgrades to accommodate OPEN are indicated in Section 4.4. 

Based upon available information, the following maior UARS functions 
have been identified: 

0 Data Ingest and L-0 Production 
0 L-0 to L-1 Production 

0 L-2 to L-3 Production 

0 Data Services To/ From Remotes 
o Remote Batch 
0 Data Management 

Based upon these functions, two functional concepts for a UARS CDHF have 
been formulated. The first concept presented is a CDHF featuring dual 
mainframe systems. The second concept presented is a CDHF configuration 
featuring a single mainframe systet;. Neither concept depends upon unique 
hardware subsystems available from only a single vendor. The dual main- 
frame and single mainframe concepts are described in Sections 4.1 and 4.2, 
respectively, and two different hardware implementations of each concept 
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are presented. Summary Information regarding significant features and 
costs are presented In Tables 4.0"! and 4.0-2. 

4 . .1 Dual Mainframe Concept 

In the dual mainframe concept tie vr.<rious CDHF functions are carried 
out by two autonomous software compatible mainframes which share a common 
data oase» and the CDHF functional workload Is split between a Production 
Processor (PP) system and a Data Manager/Processor (DM/P) system as 
Illustrated In Figure 4.I-*!. As Indicated In Figure 4.1-1, the extensive 
arithmetic and matrix manipulation services required to accomplish daily 
2 production and to provide remote batch se.rvices are provided by the PP 
and its associated array processing facilities, while the computationally 
less demanding L-0, L-1 and L-3 production services, as well as the 
(primarily) non-arithmetic data Ingestion, data management and remote site 
interface services are provided by the DM/P. 

The PP and DM/P would be sized to permit the processing of a day's 
volume of UARS data in one work shift, with capacity to spare. The PP 
would be sized in the 3 to 3.5 MIPS range, while the less powerful DM/P 
would operate in the range of 1 MIPS. 

Since the dual mainframe concept features two Independent software 
compatible mainframes sharing a common database, certain backup 
capabilities are Inherent in this approach which are not present in a 
single mainframe approach. In the event of PP outage, the DM/P and array 
processing facilities may be used to carry on UARS production at a reduced 
rate of approximately 50% (2 work shifts, with little or no margin). In 

t 

the event of DM/P outage^ the PP can assume the responsibilities of the 
DM/P and complete all daily processing tasks within 2 work shifts. 
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FIGURE 4.1-1 DUAL MAINFRAME FL.iCTIONAL CONCEPT 










Two possible hardware implementations of the dual mainframe concept 
have been prepared. The first implementation features IBM mainframes, 
while the second implementation features CDC mainframes. Both 
implementations require array processors. Tables and 4.0-*2 summarize 

these two implementations and their costs. 

4.2 Single Mainframe Concept 

The single mainframe concept accomplishes all of the CDHF functions 
using a single large mainframe. This concept is Illustrated in Figure 

4.2-1. 

As was the case with the dual mainframe concept, the single mainfrme 
is sized to permit the processing of a day's volume of UARS data in one 
work shift. However, no array processing is required. In contrast to the 
dual mainframe concept, however, the single mainframe concept does not 
Include the capability to operate at reduced levels in the event of 
mainframe failure since there is no mainframe redundancy. 

Two hardware implementations of the single mainframe concept were 
derived; IBM and CDC. Tables 4.0-1 and 4.0-2 summarize these 
Implementations and their costs . 

4.3 Production Processing Demands /Estimates for UARS 

Table 4.3-1 summarizes the minimal input, output and processing 
resources that would be consumed by the dual mainframe and single mainframe 
implementations. The values listed in this table are minimal since operat- 
ing system resource demands and system inefficiencies are not Included. 

4.4 OPEN/UARS CDHF Commonality 

Since the on-line storage required for OPEN is about 418 Gbytes (see 
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Table 3.1-2), this is in the range of the mass storage systems envisioned 
for the UARS CDHF. Thus, major UARS system upgrades are only required to 
accommodate the higher OPEN processing load. The upgrade could be 
accomplished as follows: for the dual mainframe approach, the Production 
Processor (PP) would be substantially upgraded; for the large single 
mainframe approach, array processors would be added. The latter approach 
appears to be the more straightforward and appears to offer the greater 
potential for achieving of hardware and software commonality. An 
explanation is given in the paragraphs the follow. 

Recall that for UARS, it is felt that a computer in the 10-11 
megainstructions /sec range could accommodate all UARS processing, with no 
attached array processor required, in about 3 hours (theoretical 
throughput). Since the OPEN processing load is estimated to be about 5.2 
times that of UARS (Section 3.2), it would appear that about 13.6 hours of 
the UARS mainframe would be required for OPEN. However, the attachment of 
array processors to the UARS single mainframe offers promise for signifi- 
cantly reducing the 15.2 hours demand on the computer. If this is the 
case, without substantial hardware design, commonality could be achieved. 

In addition to the common hardware design Inherent in this approach, 
there could be promise for achieving a measure of software commonality. As 
will be seen in Section 5, there appear to be substantial areas of 
commonality between the OPEN and UARS software systems both in the areas of 
data management software and the production software. If both OPEN and 
UARS processing utilized the same mainframe, then the software would be 
available to both and substantial cost savings could be realized. 
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5.0 DATA PROCESSING AND MANAGEMENT CONCEPT 


This section presents a unified data processing and management concept 
for OPEN and UARS. The approach taken is cognizant of the challenges 
offered by managing the massive volumes of data stored on-line at the 
respective CDHF's. Among these challenges are access speedy data base 
recovery and data base reorganization. Furthermore the concept presented 
here satisfies Investigator browse and retrieval requirements as well as 
the need to manage massive volumes of sequential files. In the discussion 
potential areas for using commercially available products are indicated. 

A description of a common approach to UARS and OPEN data management is 
summarized pictorial ly in Figure 5.0-1. The concept presented Incorporates 
standard system sequential file processors (vendor utilities) to manage the 
large quantities of UARS or OPEN data at the CDHF and would thus minimize 
storage overhead for these data. Use of sequential files would also 
simplify any data restoration process required to recover data destroyed as 
the result of system malfunctions. Since large sequential files do not 
lend themselves to rapid querying by remote users » a Data Locator Data Base 
(DLDB) designed for fast access would be provided to assist users in 
locating data of interest. The DLDB would be event and condition oriented 
and would be of a coarser time granularity than the UARS and OPEN data that 
is summarized. Such a data base, being a summary of the data elements used 
to derive it, could be much more compact and rapidly accessible than would 
be a data base which consists of the constituent data elements of the 
events themselves. Vectors into specific files that contained data 
corresponding to particular events or conditions would be filed in the DLDB 
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to provide the user with the information necessary to access, bro«>*ae 
through or retrieve data of interest* 

5.1 Production Cycle 

Similarities between UARS and OPEN sugges^^: that a common software 
production framework and collection of production software utilities could 
be configured for use at both GDHF^s. 

As pictured in Figure 5.0-1, a typical production cycle would begin 
with the arrival of spacecraft data via the data capture facility. Raw 
data would be read into the CDHF data processing system by the Data Ingest 
Processor, subjected to elementary quality control checks, and stored. 
Subsequently the Production Processor (PP) would be activated in turn* 
These production processors need not be unique to a particular CDHF. 
During the production processing the various PP's would input some level of 
data together with any required spacecraft or instrument oriented support 
data and produce specific higher level outputs. As various segments of 
the production process are completed, appropriate Data Scan Processors 
(DSCAN) would be activated* The function of the DSCAN processors would be 
to examine the various new production files registered in the system Master 
File Directory and to develop (predefined) summary information for 
Incorporation Into the Data Locator Data Base (DLDB). As an example, the 
DSCAN might note at which point in time a peak reading occurred in a 
particular subsystem and record such items as the value of the reading; the 
(real) time and date at which the event occurred, instrument status; the 
name of the data file containing the reading; and the relative position 
(within the data file) of the reading. Subsequently the DSCAN would submit 
this (and other) significant events data to the Data Base Management System 
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Processor for incorporation into the DLDB. Once incorporated into the 
DLDB, the significant events and vectors into the production data file 
system would be available to the user community via the Interactive Query 
Processor* 

5*2 User Interface 

Four processors are provided to allow users to submit » locate a^d 
retrieve data (see Figure 5.0-1). These processors are as follows: a Data 
Submission Processor for permitting users to submit higher level data and 
support and correlative Information; an Interactive Query Processor for 
determining availability and location of data; an Interactive Browse 
Processor for eKamining selected data fields; and a Data Retrieval 
Processor for forwarding specific data to the user site. 

5.3 Data Security 

Since the data stored at the CDHF will represent significant 
expenditures of manpower, analytic and data processing resources, it is 
essential that the CDHF Include the necessary elements of security to 
protect data from accidential or deliberate loss or destruction* The 
concept presented in Figure 5.0-1 includes provisions for data security 
that minimizes the chances for the loss or destruction of data by providing 
off-line backup copies of data and by controlling accesses to on-line data. 

The creation of the off-line backup copies of on-line data would be 
provided using File/Data Backup Processors. While processors could be 
especially written for the CDHF, in many cases off-the-shelf system 
utilities are available to provide backup file copies on magnetic tape* 
The creation of off-line backup data copies (probably using magnetic tape 
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as a backup medluni) could be an ongoing process throughout the lifetime of 
the CDHF. Furthermore, in the event of system software or hardware 
failures or user errors resulting in the loss of on~llne data, an 
appropriate File/ Data Backup Frocessor could re-establish the data on-line 
from the most recent backup copy available for that data. Such a recovery 
method would avoid the necessity of lengthy (multi-hour. In some cases) 
computer runs to recreate lost data from lower levels data. 

Since the CDHF system will be a multi-user system, access to on-line 
data will of necessity be limited to a certain degree (at a minimum it 
would be necessary to prohibit concurrent updating of the same data by 
multiple users and/or processors). In terms of Figure 5.0-1, these types 
of access control could be provided by the System File Management and 
DBMS processors. User identification codes or account numbers augmented 
(if necessary) by privilege passwords would probably prove adequate. 

5.4 Archive Function 

Depending upon the nature and compatibility of the archive medium 
and/or interface, the Archive Process^ shown in Figure 5.0-1 would prepare 
copies of archive data, using a medium such as computer compatible tape. 
While archive medium generation for production data could be postponed 
until the end of the CDHF lifetime, consideration should be given to an 
ongoing archive process (perhaps a daily or weekly archive generation run) 
throughout the CDHF lifetime. An ongoing archive process (of data which 
have become static) could preclude the necessity for an extended series of 
archive production runs involving the transfer of hundreds of billions of 
bytes of data from on-line storage. The introduction of the cond^pt of an 
ongoing archive process might also lead to significant savings in clme and 
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resources if it proved feasible to combine certain elements of the archive 
process with an ongoing data backup process. 
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6.0 COMMUNICATIONS COSTS; CDHF/ REMOTES 

In order to derive cost estimates for CDHF/Remote communications a 
comparison was made for the following three modes: 
o Packets 

o Digital Service Leased Line 
o Satellite Hop 

The comparison was made under the following assumptions: 
o Remote located 2000 miles from OSFC 

o 12 Mbytes/day of traffic (average) between GSFC and a UARS Remote 
o 38.5 Mbytes/day of traffic (average) between GSFC and an OPEN 
Remote. 

Under these assumptions a table was derived which presents a summary 
of the communications costs to the remotes (see Table 6.0-1). The cost 
figures for Packets and Digital Service Leased Line were derived from 
Fundamentals of Data Communications by Jerry Fitzgerald and Tom. S. Eason, 
1978, as well as conversations with cognizant GSFC personnel. The 
satellite communications costs were based on Planning Research Corporation 
(PRC) System Services Company's NASCOM Circuit Regression, which appears In 
Development of NASA DMS Performance/ Cost Models , dated 5 January 1982. 
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TABLE 6.0-1 


COMKOMIGATIONS COSTS (DOLLARS /MONTH/ REMOTE) 


ComBtinication Mode 

Costs (Dollars/Month/Remote) 

CARS 

OPEN 

Packets 

$18,768 

$59,274 

Leased Line 

$2,139 

$2,139 

Satellite (Domestic) 

$3,370 

$3,370 

Satellite (Overseas) 

$19,430 

$19,430 





7.0 POTENTIAL TECHNOLOGY APPLICATIONS 


The technology for Implementing the UARS and OPEN data systems exists 
at the present time. However, there are technologies that should be 
available during the mission tlme-frames that could be utilized for a more 
cost effective or better performing system. The technologies examined are 
In the areas of data management, mass storage, software language 
development and communications. 

7.1 Data Management 

The most promising potentially applicable data management technology 
is that of the data base machine. Until recently data base management 
systems (DBMS's) have been software systems which executed on standard 
general purpose computers. However, two major limitations have surfaced 
under this implementation scheme. Data management systems that run on 
conventional computers run Into bottlenecks when processing a large volume 
of transactions on very large (10 Gbytes) data bases. This Is due to the 
data staging "bottleneck" between mass storage and main memory. The second 
limitation Is that users are continually demanding more sophisticated DBMS 
capabilities such as backup and recovery. Integrity and security controls, 
etc. These capabilities are needed by OPEN and UARS and require tremendous 
overhead. Consequently, a number of researchers have proposed the use of 
dedicated or specialized processors to execute data management functions. 
These are called data base machines (DM). 

Several DM architectures are under Investigation. All involve 
parallelism In one form or another and therefore take advantage of emerging 
VLSI technology. An example of a DM available today Is a Britton~Lee 
computer designed specifically for DBMS processing. With software and 



hardware the entire system can be purchased for about $200,000 (cost will 
vary depending on data base size and options)* It is capable of data base 
access times equivalent to those obtained on a 5 to 10 MIPS standard 
computer with a software data base and there are plans to increase 
performance by another 5 to 10 fold. It will currently support up to 10 
Gbytes of disk storage. 

7 .2 Mass Storage of Data 

A common theme to the OPEN and UARS architectures discussed in this 
volume is that to achieve a balance between operational performance and 
system costs a hierarchy of computer memories/storage technologies is 
required. This hierarchy consists of a spectrum of cache/main memory, mass 
storage, and archival memory devices that span roughly six orders of 
magintude in both performance and cost. Because most technology involved 
in the existing memory hierarchy continues to reduce the per-bit storage 
cost at about the same rate, there will be no cross-over within the 
hierarchy within the near future. Therefore, memory hierarchies will 
continue to play a key role in the design of cost effective system 
architectures . 

The storage technologies for accomplishing the objectives of the OPEN 
and UARS missions are well at hand. However, although there are numerous 
choices which can be made among alternate computer systems for performing 
production and communication tasks, there are only two choices for 
implementing the mass storage function. These choices, describe previously 
in this report are the IBM Mass Storage System (MSS) and the Masstor 
Virtual Storage System (VSS). Both these systems are basically automated 
magnetic tape-cartridge read/write systems that access the appropriate 
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cartridge, load It, and transfer the data to a staging disk In a matter of 
seconds. In the near term it does not appear that these devices will be 
supplanted. However, it can be anticipated that with the continuing price 
decrease in VLSI technology, more device Intelligence will be built into 
mass storage devices. This would help remove the data**locatlon burden from 
the CPU as well as minimize I/O traffic between mass storage and tdain 
memory. Additionally there could be an implementation in the mass-^storage 
devices of such features as format initialization, limit checking, data 
compression and expansion, and error correction. 

On the horizon the only apparent alternative to the magnetic cartridge 
mass storage devices seems to be the emerging optical disk storage systems. 
Optical disks promise a higher storage density and a lower per-blt cost 
than any other mass storage medium. Additionally they are they are made of 
materials that can be stored for many years without stringent environmental 
controls. However, opltcal disks suffer the drawback of being write-once 
devices. Although most magnetic tape is used in a write-once manner, 
there is a reluctance to utilize a new technology that forces this mode of 
operations. 

At the present time, RCA has completed experimental opltcal disk 
systems that can record 5 Gbytes of data on one side of an optical disk at 
rates exceeding 100 Mbits/sec. These systems have provided a bit error 
rate of one-in-100 Mbits and can access any block of data in less than 0.5 
seconds. There are plans to design a unit that would hold a number of 
optical disk platters that would be retireved and loaded as the need arose. 
It is planned that the worst case access time for a data block in this 
system would be about 5 seconds to retrieve data from a stored disk and .5 
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seconds if the disk were already on line. This type of system has been 
proposed to have 1.25 terabytes of storage. 

Before optical data storage hardware becomes a reality, however, much 
work remains in the mechanics, the optics and the recording medium. 
Nonetheless, the current level of development activities suggests that 
operational systems will become widespread by the late 1980's or early 
1990's. 

A mass storage system that is exclusively optical disk does not appear 
feasible for OPEN and UARS-type projects because the write-once limitation 
could lead to a database size of over a terabyte. However, reversible data 
(Levels 0 and i for UARS and Level 0 for OPEN), which would rarely be 
altered, could be optically stored. An example of an advantage here could 
be the ease by which large quantities of this data could be recorded on a 
single disk (5 Gbytes or more) and sent by an express package service to 
the investigators. This could relieve a heavy I/O and communications 
burden from the CDUF. 

7 .3 Software Language Developments 

The most likely major transition in languages that can be expected 
in the near future is the acceptance and use of the Ada language. Ada is 
currently under development by the Department of Defense (DOD) to be used 
in all of their software systems. Not only is it a powerful and flexible 
structured language, but it also serves as a program support environment, 
particularly for transportability, as well as supplying a methodology for 
life cycle software development, particularly in the area of configuration 
management. The use of Ada for OPEN and DARS would require massive 
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programmer retraining, the positive features of Ada may not outweigh this 
initial disadvantage. Moreover the cost benefit of Ada has not yet been 
proved. 

Currently there are research efforts under way for producing compilers 
for automatic program generation in the sense that languages would be 
produced which would allow statements about what the program is to do to 
generate hlgh-*level language algorithms for stating how the program is to 
produce the desired results. For languages under current research, the 
compiler determines the sequence of procedures by analyzing th@ statements 
entered. Tnis is in contrast to conventional languages in which control 
flow is built into the program itself. 

At the present time there are no commercially available compilers for 
automatic program generation. It does not appear that one would be 
available for OPEN and UARS. Moreover, it remains to be seen whether 
increased hardware performance can overcome the potential slowness and 
inefficiency of multi-level compilers which first translate specifications 
into high-X<SVel languages and then into machine-language instructions , 

7 .4 Communications 

Communications will be paced by advances in satellites and optical 
fibers . 

In satellite communications, research in the areas of space diversity 
and time-division techniques, developments in antenna technology, 
sophisticated high-speed on-board switching, exploiting higher frequency 
sections of the spectrxim, and on-board error detection and correction would 
provide for much broader wideband capabilities in space. However, under 
the communications traffic assumed by UARS, for example, recurring 
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satellite and terresterlal communications costs were about the same. As 


long as rate structures are determined as a function of distance^ this can 
be expected to remain the case. It remains to be seen If this policy will 
change . 

Over the next few years local networks will be wire-based. If fiber 
Is to compete, Interfaces must be developed for fiber-optic systems that 
are compatible with coaxial networks such as Ethernet. Also, research Is 
needed to define network topologies that best utilize fiber optics. 
Standards are now being established for defining a general class of 
terminal device for an optical fiber system. A goal would be the 
interchangability of the terminal device with a terminal device for a wire- 
based network. 

Outside of local network applications, high-speed fiber optic buses 
may fill the need for fast parallel transfers between a mainframe and high- 
speed peripherals. This may serve to relieve any potential data staging 
bottlenecks between mass storage and main memory, as could be the case in 
the CDHF. 
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